![]() |
|||
![]()
|
![]() |
![]() Click Here! |
![]() |
Security Service In a large DCE, there may be hundreds or thousands of users and hosts requesting access to the cell services. Although it is very important to enforce a security mechanism, it would be impractical to replicate user and password information across all systems. Thus, a centralized security service is required. In a secure environment, the client would first obtain credentials (DCE uses the term tickets) from the security server before calling a server. The server would in turn validate the caller by making calls to the security server. This may be done on the first call by a client and may not be required thereafter, or on each call in highly secure environments. The level of security required is dictated by the server. As already noted in the description of cell security, DCE uses the Kerberos version 5 standard for security. The security information maintained by the security service is valid only for the local cell. For intercell operation, the security server obtains rights (tickets) to the foreign cell through a prearranged shared key. After obtaining a ticket to the security server of the foreign server, it can then obtain a ticket for the client from that server. The security information that is passed between systems is encrypted to ensure system integrity. DCE Process Threads DCE provides a process threads (Pthreads) package that conforms to the POSIX 1003.4a standard. Typically, applications execute sequentially and thus there is only one control path. In a multitasking operating system, there are many processes running, each with its own internal data, register information, and program counter. The operating system keeps this information separate for each process, as well as shares information among such processes as file locks. Pthreads are multiple individual control paths within a single process. Multiple control paths allow a program to be executing one part of the program while another part is waiting for input data. Using Pthreads is similar to the UNIX fork mechanism for creating multiple processes from one parent process. However, unlike the processes created by the fork mechanism, the operating system is not aware of the threads and will treat the program as one process. Each thread in a process shares the same address space and static and external data, as well as open files or other resources that are available to the whole process. This is in contrast to UNIX, where forking a child process starts with a copy of the parent programs data space but is then a separate process entirely. Because they share the same data space, Pthreads make the task of parallel processing much easier. However, for the same reasons, problems may arise if the programmer is not careful about the use of shared resources. The DCE Pthreads package contains mutual exclusion locks (mutex) and condition variables to help protect data and to synchronize processing. Pthreads are used most commonly in server applications to handle multiple concurrent requests from clients. Although this is desirable, because it does not allow a server application to cause a significant bottleneck in the performance of a client/server system, the server applications developer must be careful to protect shared data. In addition, the client application may use Pthreads to request services or data concurrently from a number of different server applications and then to assemble the results. Other client applications may use Pthreads to give control of the interface back to the user while it completes a time-consuming operation. Distributed Time Service Many applications user time to control their operations. In a distributed environment, the time on each machine may be different, which could cause problems in some applications. To overcome the problem of system clocks that are not synchronized with each other, DCE provides a time synchronization service DTS to synchronize the system clocks across all the systems in the cell. It can compute the correct time from local systems that are acting as time servers, or it can obtain the time from an external source such as the National Institute of Standards and Technology or any other standard time provider. Distributed File System The DFS allows users to access data on other systems on the network. In DCE terms, the users system is the client, and the system on which the data is stored is the server. Whenever data is accessed by a client, a copy of data from the server is cached onto the client machine. Modified data is written back to the server. For data to be modified, DCE must first assign a write token to the client. If other clients have a read token for the data, they are notified by the server that their data is no longer valid and their tokens are invalidated. DFS is based on the Andrews File System from Transarc Corp. and provides the following features:
The major differences between DFS as implemented in DCE and Sun Microsystems Network File System (NFS) are:
Diskless Workstations DFS also has support for diskless workstations using general-purpose protocols. In this case, the DFS cache manager would cache the data in the clients memory instead of to a local disk. Diskless workstations are used to save money on the purchase price of separate disks in each workstation, however, the current relative low cost of disks makes it unlikely that diskless workstations will be used in many organizations.
|
![]() |
|
Use of this site is subject certain Terms & Conditions. Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details. |